With regard to many defects of the Simple Network Management Protocol (SNMP), a Network Configuration Protocol (NETCONF) is proposed in the prior art. NETCONF overcomes the defects of SNMP basically and is applicable to management of large and complex devices. NETCONF is a configuration protocol for layered management. It provides the mechanisms such as configuration, installation, maintenance, and deletion of network devices. NETCONF uses an Extensible Markup Language (XML) to encapsulate configuration data. The protocol operations take place at the simple Remote Procedure Call (RPC) layer.
FIG. 1 shows a layered structure of NETCONF in the prior art. As shown in FIG. 1, the NETCONF protocol is conceptually divided into four layers. The first layer is the transport protocol layer. In the transport protocol layer, common protocols include the Blocks Extensible Exchange Protocol (BEEP), Secure Shell (SSH), Secure Socket Layer (SSL), and console. The second layer is the RPC layer, which includes an RPC and an RPC response. The third layer is the operations layer. In the operations layer, common operations include Get-config, Edit-config, and notification. The fourth layer is the content layer (also called the configuration management layer), which is used to manage configuration data.
In the NETCONF protocol, the system needs to provide notifications so that users know events that occur in the system in time. The events refer to events that occur on certain devices and should be noted, such as the configuration change, failure, status change, threshold crossing, and abnormal intrusion. Therefore, a NETCONF client needs to subscribe to notifications from a NETCONF server. If the subscription is successful, the NETCONF server records the subscription message of the NETCONF client in a subscription list. When an event occurs in the system, the NETCONF server sends a notification to the NETCONF client according to the recorded subscription message to inform the NETCONF client of the occurrence. If one of the following cases occurs, the NETCONF server does not send a notification to the NETCONF client: a NETCONF session is terminated; the event is beyond the subscription range; event subscription changes. It should be noted that RPC requests are never processed in a session used for the notification of events in the NETCONF server.
The preceding notification is defined only according to the lower three layers of NETCONF, and no notification mode is defined according to the entire NETCONF-based four-layer structure in the prior art. Therefore, it is expected that a similar notification mode in other application environments in the prior art will be adopted to implement NETCONF-based notifications.